As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Deploying a new software application or program feature for an information handling system may require an updated target software stack to satisfy prerequisite shared libraries for the new application. Thus, the target software stack must be updated to the compatible version of the dependent libraries before the shared library version of the application can be executed. However, the installation of an additional (updated) library package may be intrusive to the stability of the software library or operability of a data center operation in which other applications are executing. To address this problem, the required updated library or libraries may be statically linked to the new application so that the dynamically-linked shared libraries of the software stack do not have to be updated. However, such a conventional approach increases the runtime memory usage when the dependent shared libraries are actually already available in the target stack.
FIG. 1 is a simplified diagram that shows a conventional relationship of software and hardware components of an information handling system 100. In particular, FIG. 1 shows an application 102 running with an operating system (OS) 104 on hardware 106 (including processing device) of the information handling system 100 using dynamic linking and first (non-upgraded) versions of shared libraries 110a-110d. Application 102 is contained in private memory space of volatile random access memory (RAM) of information handling system 100, and dynamically-linked shared libraries 110a-110d are contained in shared memory space of RAM of information handling system 100. In this way, dynamically-linked shared libraries 110a-110d are available to other applications loaded into RAM of information handling system 100.
FIG. 2 shows another conventional relationship of software and hardware components of the example information handling system 100. In particular, FIG. 2 shows the same application 102 running with an operating system (OS) 104 on hardware 106 (including processing device) of the information handling system 100 using updated dynamically-linked shared libraries 120a-120d which represent upgraded versions of the libraries of FIG. 1 that are contained in shared memory space of random access memory RAM of information handling system 100, and therefore available to other applications loaded into RAM of information handling system 100.
FIG. 3 shows another conventional relationship of software and hardware components of the example information handling system 100. In particular, FIG. 3 shows the same application 102 loaded into system RAM and running with an operating system (OS) 104 on hardware 106 (including processing device) of the information handling system 100. Also present in RAM are non-upgraded dynamically-linked shared libraries 110a-110d. As shown, an additional statically-linked upgraded library 120c that is needed by application 102 is also included in the application image that is contained in the private memory space of application 102. In this case, upgraded statically-linked library 120c is needed by application 102, and non-upgraded dynamically-linked library 110c remains present in shared memory space but is not used by application 102. Non-upgraded dynamically-linked library 110c is, however, available for use by any other application that needs this version of library 110c. Therefore, in the conventional case of FIG. 3, RAM memory space is required to simultaneously contain both non-upgraded library version 110c and upgraded library version 120c. In the case that upgraded library version 120c is already loaded in RAM as a dynamically-linked shared library, then the additional RAM memory space required to contain upgraded statically-linked library 120c that is loaded with application 102 image is wasted.
FIG. 4A is a simplified flowchart showing conventional methodology 400 for loading of an application 102 from relatively inexpensive disk or other non-volatile storage into relatively expensive volatile system RAM, followed by linking, and running of the application on hardware of an information handling system. As shown, methodology 400 starts in step 402, where an executable application file (in Extensible Linking Format or Executable and Linkable Format “ELF”) is parsed. Next, in step 404, shared dependent libraries needed by the application are found, loaded (if needed) into system RAM and linked-to in an iterative manner. In step 406, if not all shared dependent libraries needed by the application are found to be present, then methodology 400 proceeds to step 408 where an error is reported and the methodology ends. However if all shared dependent libraries needed by the loaded application are found to be present, methodology 400 proceeds to step 410 where the shared dependent libraries are evaluated for compatibility with the application by determining if all symbols referenced by the application are present in the existing shared dependent libraries. If all referenced symbols are not resolved or present in the existing libraries, then methodology 400 proceeds to step 412 where an error is reported and the methodology ends. However if all referenced symbols are resolved, and then final full application image is successfully linked and loaded, then the application is run in step 414 as shown.
FIG. 4B is a simplified illustration of the contents of a conventional executable application program object file 450 in ELF format for an application 102. As shown, file format 450 includes ELF headers 452, text section 454, data section 456, bss section 458 and various other sections 460. Each of sections 452, 456 and 458 include a respective header and data as shown.
Weak symbol binding as used in compilers like GNU compiler collection (GCC) with “#pragma weak” and “_attribute_((weak))” allow a symbol to have special properties when dynamic linking with libraries is used. One use is to allow an application to adapt to differing versions of support libraries. If the application would like to use a feature in a new version of a library, but the runtime of the information handling system has an older version of that library, the symbol will be zero or NULL.